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REMARKS 

This Application has been reviewed in light of the Advisory Action mailed October 
24, 2008. At the time of the Advisory Action, Claims 1-12 and 14-22 were pending in this 
Application. Claims 1-12 and 14-22 were rejected. Claim 13 was previously cancelled. 
Applicants request reconsideration and allowance of all pending claims. 

Claim Objections 

Claims 9-22 were objected to based on the use of the term "tangible" in Claims 9-22. 
Although Applicants disagree with this objection, Applicants have amended the claims to 
remove the term "tangible." Independent Claim 9 has been amended to recite "A program 
product for automatically naming hosts in a distributed data processing system, the program 
product stored in one or more hardware memory components and comprising ..." 
Independent Claim 16 has been amended to recite "a network interface in communication 
with a plurality of hosts, a processor in communication with the network interface, data 
storage hardware in communication with the processor, and computer instructions stored in 
the data storage hardware , wherein, when the computer instructions are executed by the 
processor, the computer instructions perform operations comprising ..." 

The Specification provides support for these amendments. For example, the 
Specification, at page 8, lines 11-25, explains: 

Cluster controller 20 and hosts 22 each include a processing core 
with at least one central processing unit (CPU), as well as data storage in 
communication with the processing core. The data storage is used to 
hold or encode data and computer instructions for automatically 
naming the hosts. The data storage may be implemented as one or 
more hardware components from technologies including random 
access memory (RAM), read-only memory (ROM), disk drives, other 
non-volatile memory components, or any other suitable technology . 
The computer instructions may also be referred to generally as a program 
product or specifically as auto-host-naming software. In alternative 
embodiments, some or all of the control logic for automatically assigned 
host names may be implemented in hardware, (emphasis added) 

Accordingly, Applicants request that the objection to Claims 9-22 be withdrawn. 
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Rejections under 35 U.S.C. §103 

Claims 1-4, 6, 9-11, 16-18, and 22 stand rejected under 35 U.S.C. §103 (a) as being 
unpatentable over U.S. Patent Application Publication 2002/0161868 by Chakkalamattam J. 
Paul et al. ^PauF) in view of U.S. Patent 5,974,547 issued to Yevgeniy Klimenko 
("Klimenko"). Claims 5, 7-8, 12, 14-15, 19 and 21 stand rejected under 35 U.S.C. §103(a) as 
being unpatentable over Paul, in view of Klimenko, in further view of U.S. Patent No. 
5,864,656 issued to Jee-Kyoung Park ("Park"). 

In Applicants' October 10, 2008 Response to Final Office Action, Applicants 
explained that the § 103(a) rejections set forth in the July 10, 2008 Final Office Action ("Final 
Office Action") were identical to those previously presented by the Examiner, e.g., in the 
Final Office Action mailed October 4, 2006 and the Non-Final Office Action mailed January 
14, 2008. In the interest of efficiency, Applicants explained that they maintained their 
positions regarding the §103 (a) rejections from previous papers, instead of copying the 
arguments in full into the October 10, 2008 Response to Final Office Action. 1 

However, the Examiner apparently found this to be insufficient, explaining in the 
Advisory Action that "Applicant also includes a heading for a response to the 103 rejection 
but does not present any arguments." Thus, Applicants provide their arguments regarding the 
Examiner's §103 (a) rejections below. 

A. Rejection under 35 U.S.C. $ 103(a) over Paul in view <?/*Klimenko. 

(1) Claims 1-4, 6, 16-18, and 20 

Summary: 

The rejection of independent Claims 1 and 16 as being unpatentable under 35 U.S.C 
§ 103(a) over Paul in view of Klimenko is improper because neither o/Paul nor Klimenko, 
individually or in combination, disclose, teach or suggest the combination of elements recited 
in Claims 1 or 16. 

The rejection of dependent Claims 2-4 and 6 is improper at least because they depend 
from and provide further patentable elements to independent Claim 1. 

The rejection of dependent Claims 17-18 is improper at least because they depend 
from and provide further patentable elements to independent Claim 16 . 



1 Applicants explained that "Once again, Applicants maintain their positions regarding these rejections (as stated 
in the Appeal Brief filed December 13, 2007, the Response to Final Office Action mailed February 5, 2007, and 
the Response to Non-Final Office Action April 14, 2008)," (October 10, 2008 Response to Final Office Action, 
page 10) 
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It is a bedrock principle of patent law that, in order to establish a prima facie case of 
obviousness, the references cited by an Examiner in an Office Action must disclose all 
claimed elements. In re Royka, 490 F.2d 981, 180 U.S.P.Q. 580 (C.C.P.A. 1974). 

Applicants contend that the art cited by the Examiner cannot render the rejected 
claims obvious, at least because the cited prior art references, taken separately or in 
combination, fail to disclose, teach or suggest all elements of the rejected claims. 

For example, Claim 1 recites: 

1. A method for automatically naming hosts in a 
distributed data processing system, the method comprising: 

(a) receiving a unique identifier (UID) at a cluster controller 
from each of a plurality of hosts in communication with the cluster 
controller, while at least one of the plurality of hosts is executing in a 
pre boot execution environment; 

(b) in response to receiving the UIDs, causing the plurality of 
hosts to produce ready signals; 

(c) receiving user input from a first host among the plurality of 
hosts, the user input comprising notification of the insertion of a disk 
within the first host; 

(d) in response to receiving the user input from a first host, 
associating a first host name with the UID for the first host; 

(e) after associating the first host name with the UID for the 
first host, causing the first host to produce a completion signal; 

(f) receiving user input from a second host among the plurality 
of hosts; and 

(g) repeating the operations of receiving replies from hosts, 
associating host names with UIDs, and causing hosts to produce 
completion signals, until each of the plurality of hosts has been named, 
such that the user input dictates the order in which host names are 
assigned to the multiple hosts. 

[Note: reference letters (a)-(g) are included for reference only and are not actually 
included in the pending claims.] 
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Applicants maintain that Paul and Klimenko, whether considered alone or in 
combination, fail to teach or suggest nearly every element — in particular, elements (a), (b), 
(c), (d), (e), and (g) » of Claim 1 . As Applicants show below, the passages of Paul and 
Klimenko cited by the Examiner clearly do not teach these or suggest elements. In fact, in 
some instances, the portions of Paul and Klimenko cited by the Examiner are not even 
remotely similar to the elements of Claim 1 . 

Provided below is an element-by-element explanation of how each of elements (a), 
(b), (c), (d), (e), and (g) of Claim 1 are not taught or suggested by Paul or Klimenko. 

(a) receiving a unique identifier (UID) at a cluster controller from 
each of a plurality of hosts in communication with the cluster controller, 
while at least one of the plurality of hosts is executing in a pre boot 
execution environment; 

The Examiner alleged in the Final Office Action that this element is disclosed at Paul, 
paragraph 32. However, paragraph 32 of Paul simply discloses: 

[0032] PXE specifies the protocols by which a client requests and 
downloads an executable image from a boot server. PXE does not specify 
the operational details and functionality of the network bootstrap program 
(NBP) that the client receives from the server, i.e. the remote boot image 
downloaded by the PXE client via TFTP or MTFTP (Multicast TFTP). In 
general, the execution of the downloaded NBP initiates a series of 
processing steps on the client that ultimately will result in the client being 
ready for use by its user. Typically, the NBP will use an application 
program interface (API) specified by PXE and provided by the client PXE 
support to request and install additional files via M/TFTP from the boot 
server containing executable images of an operating system, appropriate 
communications and other device drivers, and other system software. The 
NBP will then transfer client execution to the operating system which can 
use either PXE or its own communications support to request user-specific 
configuration information and application software executable images 
from the boot server for installation on the client. 

As Applicants have previously explained, this passage merely explains that the 
Preboot Execution Environment (PXE) specifies the communication protocols that a client 
may use to request a network bootstrap program (NBP) from a boot server, and that when 
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executed, the NPB requests and installs additional files from the boot server in order to ready 
the client for use. 

Paragraph 32 discloses nothing that could be equated with a " unique identifier 
(TJIDV much less "receiving a unique identifier (UID) at a cluster controller from each of a 
plurality of hosts," as recited in Claim 1. After reviewing Paragraph 32 in light of element 
(a) of Claim 1, Applicants requested that the Examiner indicate precisely which element 
recited in Paragraph 32 the Examiner believes could be equated with the "unique identifier 
(UID)" that is received at a cluster controller from each of a plurality of hosts. (See February 
5, 2007 Final Office Action Response, page 9). However, the Examiner refused to provide 
such indication, instead accusing the Applicants of reading the passages "with out context" 
(See Feb. 14, 2007 Advisory Action, Page 2). 

(b) in response to receiving the UIDs, causing the plurality of 
hosts to produce ready signals ; (emphasis added) 

The Examiner alleges that this element is disclosed at Paul, paragraph 35. (Final 
Office Action). However, paragraph 35 of Paul simply discloses: 

[0035] In the PXE protocol, DHCP option fields are used to perform 
the following: (a) distinguish between DHCPDISCOVER and 
DHCPREQUEST packets sent by a client as part of this extended protocol 
from other packets that the DHCP server or boot server might receive; (b) 
distinguish between DHCPOFFER and DHCPACK packets sent by a 
DHCP or Proxy DHCP server as part of this extended protocol from other 
packets that the client may receive; (c) convey the client system's ID (in 
most cases, the client's UUID--Universally Unique Identifier) to the 
DHCP and boot server; (d) convey the client system's architecture type to 
the DHCP server and boot server; and (e) convey the boot server type 
from which the client is requesting a response. Based on any or all of the 
client network adapter type, system architecture type, and client system 
ID, the boot server returns to the client the file name (on the server) of an 
appropriate NBP executable. The client downloads the specified NBP 
executable into memory and then executes it. As noted above, the 
functionality within the downloaded NBP is not specified by the PXE 
protocol. 

The passage discusses various functions performed by DHCP option fields in the PXE 
protocol, which includes conveying various data between a client, a DHCP server, and a boot 
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server, including "convey [ing] the client system's ID (in most cases, the client's UUID-- 
Universally Unique Identifier) to the DHCP and boot server." Based on the client UUID and 
other data, the boot server sends the client the file name of a particular network bootstrap 
program (NBP) executable, which the client then downloads and executes in order to boot the 
client. 

The passage does not disclose anything about " causing the plurality of hosts to 
produce ready signals ," much less doing so "in response to receiving [unique identifiers from 
each of the plurality of hosts]," as recited in Claim 1. There is no disclosure of a ready 
signal, much less causing multiple hosts/clients to produce a ready signal in response to 
receiving identifiers from the multiple hosts/clients. 

Applicants have previously requested that the Examiner indicate precisely which 
action disclosed in Paragraph 35 of Paul could be equated with " causing fal plurality of hosts 
to produce ready signals ," in response to receiving unique identifiers from each of the 
plurality of hosts. (See February 5, 2007 Final Office Action Response, page 9). However, 
the Examiner merely accused the Applicants of reading the passages "with out context," as 
discussed above. (See Feb. 14, 2007 Advisory Action, Page 2). 

(c) receiving user input from a first host among the plurality of 
hosts, the user input comprising notification of the insertion of a disk 
within the first host; 

The Examiner correctly acknowledged in the Final Office Action that Paul fails to 
teach this element. Instead, the Examiner alleges that this element is disclosed at Klimenko, 
Col. 4, lines 17-63. However, Column 4 5 lines 17-63 of Klimenko merely recites: 

While the boot process is occurring but prior to the availability of any 
client O/S-based network support, client hard disk emulation occurs through 
appropriate calls made to an interrupt (Interrupt 13 or simply "Int 13") handler. 
Through such calls, appropriate sectors in the client image file are initially 
downloaded, via a real-mode network adapter (NIC) driver and the Int 13 
Handler to remotely install various components of the O/S into client PC. The 
actual client hard disk emulation process is provided through a real mode 
procedure that executes as part of Int 1 3 Handler. In essence, the real mode 
procedure determines, based on values of status flags, whether the client O/S is 
then capable of handling a network request for sector access of the client image 
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file. If the client O/S has not then progressed to that point in its boot process, 
the real mode procedure processes that request, in real mode, through the Int 1 3 
Handler. 

As a client O/S kernel is installed and initialized during the boot 
process, the kernel installs and activates various device drivers, including the 
inventive LANHDVSD.VXD procedure. This procedure is compliant with 
both the Int 13 Handler and with the O/S, specifically, in the case of Windows 
95 O/S, a network driver (NDIS-network driver interface specification) kernel 
therein and the O/S input/output subsystem (IOS). The inventive procedure, 
which executes as a protected mode driver, contains two asynchronous 
procedures. These asynchronous procedures, by setting and testing appropriate 
flags used as processing state semaphores, collectively control the transition of 
hard disk requests to the networked client image from the Int 13 Handler to the 
client O/S depending upon, as the client O/S is then booting, the O/S resources 
that are then available. During early phases of the boot process, insufficient 
O/S components have been loaded and activated to provide client O/S 
supported network access. Consequently, client hard disk access requests are 
handled through the Int 13 Handler. Whenever sufficient O/S resources 
become available to permit network access through the client O/S, the 
asynchronous procedures permit these requests to be serviced by the NDIS and 
IOS components of the client O/S, so as to provide O/S supported network 
access, rather than by the Int 13 Handler. Hence, these asynchronous 
procedures collectively assure, in conjunction with Int 13 Handler, seamless 
and continuous client hard disk emulation during the real-protected transitory 
state. 

As Applicants explained in the Final Office Action Response, there is nothing in this 
passage regarding the insertion of a disk within a host , much less receiving a " notification of 
the insertion of a disk within Tal host ." In fact, the only mention of a disk in the passage 
regards a "client hard disk emulation process," which does not concern the insertion of a disk 
within a host or a notification of such an insertion of a disk. Thus, Klimenko cannot teach 
this element. 
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(d) in response to receiving the user input from a first host, 
associating a first host name with the UID for the first host ; (emphasis 
added) 

The Examiner alleges that this element is disclosed at Paul, paragraph 35. Paragraph 
35 of Paul is reproduced above regarding element (b). 

As Applicants explained in the Final Office Action Response, Paragraph 35 fails to 
disclose a client having both a "host name" and a "unique identifier (UID)" for a particular 
host , much less associating the host name with the "unique identifier (UID) for the particular 
host. Even assuming for the sake of argument that the "client's UUID-Universally Unique 
Identifier" disclosed in Paragraph 35 of Paul could be equated with the "unique identifier 
(UID) for [a] host" of Claim 1, Paul fails to disclose associating a host name with the client's 
UUID. Further, Paragraph 35 fails to disclose making any association of names or identifiers 
for a host "in response to receiving . . . user input from [the] host." 

After reviewing Paragraph 35 of Paul in light of element (d) of Claim 1, Applicants 
requested that the Examiner indicate precisely which elements disclosed in Paragraph 35 can 
be equated with the "first host name" and the "unique identifier (UID)" for a first host, as 
well as the operation that can be equated with associating a "first host name" with the 
"unique identifier (UID)" for a first host. {See Feb. 5 5 2007 Final Office Action Response, 
page 10). However, the Examiner merely accused the Applicants of reading the passages 
"with out context," as discussed above. {See Feb. 14, 2007 Advisory Action, Page 2). 

(e) after associating the first host name with the UID for the first 
host, causing the first host to produce a completion signal; 

The Examiner alleges that this element is disclosed simply at "(Paul, )." This is the 
full extent of the Examiner's explanation of how Paul teaches element (e) of Claim 1. 
Applicants pointed out this deficiency to the Examiner {See Final Office Action Response, 
page 1 0), but the Examiner declined to correct the deficiency. 

Applicants assume that the Examiner either forgot to include the paragraph reference, 
or could not find any portion of Paul that could be equated with this element of Claim 1. In 
any event, the rejection is improper because the Final Office Action failed to cite the prior art 
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with sufficient specificity under 35 U.S.C. $ 132 and 37 C.F.R. § 1.104 to allow Applicants 
to adequately respond to the rejections. 

First, the Final Office Action does not comply with the intent and purpose of 35 
U.S.C. § 132 because it fails to properly identify and clearly explain the portions of the cited 
prior art that allegedly teach element (e) of Claim 1 . 

In addition to defeating the intent and purpose of 35 U.S.C. § 132, the Final Office 
Action does not comply with the requirements of 37 C.F.R. § 1.104 due to lack of specificity. 
37 C.F.R. § 1.104(c)(2) states: 

In rejecting claims for want of novelty or obviousness, the examiner 
must cite the best references at his or her command. When a reference 
is complex or shows or describes inventions other than that claimed by 
the applicant, the particular part relied on must be designated as nearly 
as practicable. The pertinence of each reference, if not apparent, must 
be clearly explained and each rejected claim specified, (emphasis 
added). 

Because the Final Office Action fails to cite any particular portion of Paul that 
allegedly teaches the element of Claim 1 recited above, the Final Office Action fails to 
comply with both 35 U.S.C. § 132 and 37 C.F.R. § 1.104. 

(g) repeating the operations of receiving replies from hosts, 
associating host names with UIDs, and causing hosts to produce 
completion signals, until each of the plurality of hosts has been named, 
such that the user input dictates the order in which host names are 
assigned to the multiple hosts , (emphasis added) 

The Examiner alleges that these elements are disclosed at Paw/, paragraphs 52 and 64. 
Paragraph 52 of Paul discloses that PXE clients broadcast initial request packets in a network 
with redundant boot servers. An initial request packet broadcast from a PXE client is 
received by all boot servers in the network. Any of the boot servers having a properly 
configured DHCP server service can respond to the initial broadcast request packet. The 
PXE client can receive one or more boot server responses and choose a response which 
directs it to a boot server to complete its remote boot. 

Paragraph 64 of Paul discloses that a determination is made regarding the availability 
of a local server for booting additional clients and the availability of other servers that have 
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reported that they are booting additional clients. A determination is then made as to whether 
or not a PXE Proxy service is currently executing. 

Thus, these paragraphs fail to disclose "associating host names with UIDs" or 
"causing hosts to produce completion signals." These paragraphs also clearly fail to disclose 
repeating a set of operations "until each of the plurality of hosts has been named, such that 
the user input dictates the order in which host names are assigned to the multiple hosts ." 
Nothing in Paragraphs 52 or 64 of Paul discloses a user dictating the order in which host 
names are assigned to multiple hosts, much less by inserting a disk or disks into the multiple 
hosts in a desired order. 

For at least the reasons discussed above, Paul and Klimenko, whether considered 
alone or in combination, fail to teach or suggest several elements of Claim 1 . For the same of 
analogous reasons, the Paul and Klimenko fail to teach or suggest similar elements of 
independent Claim 16. Accordingly, the cited references cannot render Claims 1 or 16 
obvious. 

Therefore, Applicants contend that the arguments provided in the Final Office Action 
and maintained by the Advisory Action are clearly flawed and the teachings of the cited 
references do not render Claims 1 or 16 obvious. In addition, Applicants contend that the 
rejections of Claims 2-4 and 6 (which depend from Claim 1) and Claims 17-18 and 20 (which 
depend from Claim 16) are improper because such Claims depend from a claim shown to be 
allowable above. 
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(2) Claims 9-11 and 22 

Summary: 

The rejection of independent Claim 9 as being unpatentable under 35 U.S.C. § 103(a) 
over Paul in view of Klimenko is improper because neither of Paul nor Klimenko, 
individually or in combination, disclose, teach or suggest the combination of elements recited 
in Claim 9. The rejection of dependent Claims 10-11 and 22 is improper at least because 
they depend from and provide further patentable elements to independent Claim 9. 

Claim 9 recites: 

9. A program product for automatically naming hosts in a 
distributed data processing system, the program product comprising: 

(a) computer instructions enabling a controller in said distributed 
data processing system to: 

(i) receive a unique identifier (UID) from a first host in 
communication with a cluster controller, at least one of the plurality 
of hosts not having a fully functional operating system present 
thereon; 

(ii) in response to receiving the UID, cause the first host to 
produce a ready signal; 

(iii) receive user input from the first host; 

(iv) in response to receiving the user input from the first host, 
associate a first host name with the UID for the first host; and 

(v) after associating the first host name with the UID for the 
first host, cause the first host to produce a completion signal; and 

(b) a computer-usable medium encoding the computer instructions. 

[Note: reference letters (a), (b), and (i)-(v) are included for reference and are not 
actually present in the pending claims.] 

Regarding the substantive rejection of Claim 9, Applicants contend that the 
Examiner's rejection of Claim 9 under 35 U.S.C. § 103(a) as being unpatentable over Paul in 
view of Klimenko is improper because neither of Paul nor Klimenko, individually or in 
combination, disclose, teach or suggest the combination of elements recited in Claim 9. 

The Examiner rejected Claim 9 based on the same rationale as Claim 1. {See Final 
Office Action, Page 7: "Claims 9-11, 16-18 and 22 are directed to the same invention as 
claims 1-4 and 6. Therefore, the supporting rationale of the rejection to claims 1-4 and 6 
applies equally as well to claims 9-11, 16-18 and 22"). 
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Applicants contend that Paul and Klimenko fail to teach or suggest various elements 
of Claim 9 for similar or analogous reasons that Paul nor Klimenko fail to teach or suggest 
particular elements of Claim 9. For example; 

• Paul and Klimenko fail to teach or suggest " receive a unique identifier (TJID) 
from a first host in communication with a cluster controller, at least one of the 
plurality of hosts not having a fully functional operating system present 
thereon " for similar or analogous reasons that Paul nor Klimenko fail to teach 
or suggest element (a) of Claim 1, discussed above. 

• Paul and Klimenko fail to teach or suggest " in response to receiving the UID, 
cause the first host to produce a ready signal " for similar or analogous reasons 
that Paul nor Klimenko fail to teach or suggest element (b) of Claim 1, 
discussed above. 

• Paul and Klimenko fail to teach or suggest " in response to receiving the user 
input from the first host, associate a first host name with the UID for the first 
host " for similar or analogous reasons that Paul nor Klimenko fail to teach or 
suggest element (d) of Claim 1, discussed above. 

• Paul and Klimenko fail to teach or suggest " after associating the first host 
name with the UID for the first host, cause the first host to produce a 
completion signal " for similar or analogous reasons that Paul nor Klimenko 
fail to teach or suggest element (e) of Claim 1, discussed above. 

For at least the reasons discussed above, Paul and Klimenko, whether considered 
alone or in combination, fail to teach or suggest several elements of Claim 9. Accordingly, 
the cited references cannot render Claim 9 obvious. 

Therefore, Applicants contend that the arguments provided in the Final Office Action 
and maintained by the Advisory Action are clearly flawed and the teachings of the cited 
references do not render Claim 9 obvious. In addition, Applicants contend that the rejections 
of Claims 10-11 and 22 (which depend from Claim 9) are improper because such Claims 
depend from Claim 9, shown to be allowable above. 
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B. Rejection under 35 U.S.C. $ 103(a) over Paul in view o/~ Klimenko and further in 
view fl/Tark 

(1) Claims 5, 7, 8, 12, 14, 15, 19, and 21 

Summary: 

The rejection of dependent Claims 5, 7, 8, 12, 14, 15, 19, and 21 as being 
unpatentable under 35 U.S.C § 103(a) over Paul in view o/Klimenko and further in view of 
Park is improper because Claims 5, 7, 8, 12, 14, 15, 19, and 21 depend from and provide 
further patentable elements to independent Claims 1, 9, and 16 shown to be allowable in 
subsection A above. 

Applicants contend that the Examiner's rejection of dependent Claims 5, 7, and 8 as 
being unpatentable under 35 U.S.C, § 103(a) over Paul in view of Klimenko and further in 
view of Park is improper because Claims 5, 7, and 8 depend from and provide further 
patentable elements to independent Claim 1, shown above to be allowable. 

Applicants further contend that the Examiner's rejection of dependent Claims 19 and 
21 as being unpatentable under 35 U.S.C. § 103(a) over Paul in view of Klimenko and further 
in view of Park is improper because Claims 19 and 21 depend from and provide further 
patentable elements to independent Claim 16, shown above to be allowable. 

Applicants further contend that the Examiner's rejection of dependent Claims 12, 14, 
and 15 as being unpatentable under 35 U.S.C. § 103(a) over Paul in view of Klimenko and 
further in view of Park is improper because Claims 12, 14, and 15 depend from and provide 
further patentable elements to independent Claim 9, shown above to be allowable. 
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CONCLUSION 

Applicants have now made an earnest effort to place this case in condition for 
allowance in light of the amendments and remarks set forth above. Applicants request 
reconsideration and allowance of Claims 1-12 and 13-21. 

Applicants respectfully submit a Request for Continued Examination (RCE) 
Transmittal, along with a Petition for Two-Month Extension of Time. The Commissioner is 
authorized to charge the fees of $810.00 and $490.00 required to Deposit Account 50-2148 in 
order to effectuate these filings. 

Applicants believe there are no additional fees due at this time. However, the 
Commissioner is hereby authorized to charge any fees necessary or credit any overpayment 
to Deposit Account No. 50-2148 of Baker Botts L.L.P. 

If there are any matters concerning this Application that may be cleared up in a 
telephone conversation, please contact Applicants' attorney at 512.322.2689. 

Respectfully submitted, 
BAKER BOTTS L.L.P. 
Attorney for Applicants 




Eric M. Grabski 
Reg. No. 51,749 



Date: December 10, 2008 
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Baker Botts l.l.p. 
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